The Hyper Text Transfer Protocol (HTTP) as defined by the Internet Engineering Task Force (IETF) in Request For Comment (RFC) 2616 is a very widely deployed protocol for computer-to-computer communications. It is so widely supported by intermediate networking equipment such as IP firewalls and Proxies that leveraging this transport protocol for application-to-application messaging is very desirable. So much so that emerging Web Services standards defined by the World Wide Web Consortium (W3C) rely very heavily, although not exclusively, on HTTP as a transport. In fact, the SOAP specification (http://www.w3.org/TR/2003/REC-soap12-part0-20030624/) published by the World Wide Web Consortium (W3C) and the basis for Web Services, specifically calls out a method of delivering SOAP messages using HTTP—referred to as the SOAP HTTP Binding. In this specification, use of HTTP POST and HTTP GET are described for use in delivering SOAP messages. However, along with the many benefits of using HTTP for delivery of messages between applications come several limitations when what is required is asynchronous, low latency message delivery to HTTP client (rather than server) devices, optionally with assured delivery. Use of an HTTP server is less desirable than an HTTP client in some cases where the application receiving the asynchronous messaging needs to have a small RAM and CPU footprint on the end device or where the application's IP address needs to be dynamically assigned rather than fixed, or where the application is behind an IP firewall and thus not allowed to accept incoming TCP connections due to security concerns. The fact that it is desirable to have (a) an HTTP client application (b) receive asynchronous messages with low latency and optionally in an assured manner is what causes the problem because HTTP is an asymmetric protocol inherently designed for request-response style message exchange patterns with the HTTP client initiating the request-response exchange. In this case, what is required is that the message exchange actually be initiated by the HTTP server application. Web Services standards and the like resolve the issue of low latency asynchronous messaging by having the receiving application be an HTTP server to which the source of asynchronous messages (acting as an HTTP client) sends HTTP POST messages, which is the opposite of what is required in this use case for reasons explained above. Alternatively, the HTTP Client wishing to receive messages can send an HTTP GET message periodically to the HTTP Server to poll for messages to be received as described in the SOAP specification. However, this polling mechanism either introduces too much delay in message delivery for some applications, or results in excessive network traffic if the polling rate is reduced. Also, there is no mechanism for providing assured delivery of messages to the receiving application—where the sending HTTP server can be sure that the receiving application has indeed received and processed the message. Even with use of TCP, the underlying transport protocol for HTTP, to guard against packet loss in the underlying IP network, it is possible for an HTTP Server to send data into the TCP connection and have the receiving HTTP Client fail or for connectivity to be lost, resulting in the HTTP Client not receiving the message without the knowledge of the HTTP Server. It is the aim of this invention to resolve these limitations in the current use of HTTP in order to provide an asynchronous, low latency delivery mechanism from an HTTP server to an HTTP client with optional assured delivery of messages.